(Special Focus - Java Technologies)(Disc 1).ISO/products/Software/AppliedReasoning/cblogo1sm.gif)
Frequently
Asked Questions
Classic BlendÖ-Next
Generation
Why use Classic Blend û Next Generation?
Can you elaborate on using Classic Blend
to develop n-tiered applications simply?
Why do I need a thin client?
CanÆt I just use Java Server Pages, JavaScript,
HTML, etc?
Is Classic Blend NG an Application Server?
What is a Presentation Server?
What is the difference between an Application
Server and a Presentation Server?
How does this differ from a Java based client
solution using CORBA or RMI?
What are the bandwidth requirements of Classic
Blend?
Can I fit a "big" application on a tiny
Network Computer?
This sounds a lot like X-Windows or WinFrame.
Is it?
But canÆt Java on the client deliver the
same thing?
Why use Classic Blend û Next Generation?
The primary benefits are:
Can you elaborate on using Classic
Blend to develop n-tiered applications simply?
Building distributed applications is often very difficult.
These difficulties stem from maintaining multiple code bases. The code
on the client must be maintained and kept in sync with the server code.
Debugging distributed applications is very challenging and once all the
bugs are out, attention must be turned to performance, which is often poor.
Classic Blend eliminates all three of these issues. There is only one code
base to maintain, all debugging occurs on the server per usual, and the
Classic Blend has been highly optimized.
Why do I need a thin client?
Having a thin-client makes deployment much more manageable
û a 250 KB download is even tolerable over a 28.8k connection. If you desire
you can also install Classic Blend on each userÆs desktop using distribution
technology such as InstallAnywhere™, or use push technology such
as Marimba® Castanet™ or Microsoft® Cabinet Manager to
implement intelligent caching. Because the application logic code only
exists on the server, changes are managed from the server and do not have
to be pushed out to each of the clients. When the application logic code
is updated on the server, all of the clients will automatically include
those changes without requiring any client-side updates.
The Gartner Group estimates that it costs $1000 per user per year for every application that must be maintained on a client's machine. This means that if your organization has 100 users of 5 different applications that must be manually installed and maintained on their machines, then this will cost your organization an average of $500,000 every year to support those applications. However, these costs can be eliminated if the application doesnÆt have to be installed and updated on each machine. An automatically downloaded client (like Classic Blend) provides just such a solution.
CanÆt I just use Java Server Pages,
JavaScript, HTML, etc?
HTML excels at displaying static page-based information.
While there are advantages to a page-based model it explicitly limits the
sophistication of the GUI. And as one attempts to add more complex behavior
to the page-based model, the development quickly becomes complex and expensive
to maintain. In addition, the page-based model is much more bandwidth expensive
because an entire page of information and widgetry must be sent to update
the GUI.
Is Classic Blend NG an Application
Server?
No, Classic Blend is not a fully blown application server.
Classic Blend is often used in conjunction with application servers but
is considered a Presentation Server. In addition, Classic Blend can be
used in conjunction with other 3rd party tools to develop custom-built
application server solutions.
The Classic Blend û Next Generation documentation describes how the product easily integrates with an application server, and provides some sample code for doing so with several popular application servers. Classic Blend - Next Generation has been built as a complementary solution to the problems of enterprise computing. That is, it is not designed to be a complete solution to all distributed application problems, rather a solution to one specific problem û how to build responsive, fully-featured, distributed graphical user interfaces. And as such, it has been designed to be used with other products and solutions. CB-NG integrates with any bean compliant Java development environment (Symantec VisualCafe, Borland JBuilder, IBM VisualAge for Java, etc.) It can be used with Application Servers (WebLogic, WebSphere, etc.), Enterprise Java Beans, and other middleware technology.
What is a Presentation Server?
A Presentation Server is concerned with distributing
just the visual GUI rendering portion of an application, not the presentation
logic, business logic, or database tier.
What is the difference between an Application
Server and a Presentation Server?
In a typical three-tier application, the application
server represents the middle tier that connects the third (GUI) tier with
the first (database) tier. A Presentation Server takes the GUI layer of
the first tier and distributes part of the GUI on the client and part of
the GUI on the server and then manages the connection between the two.
How does this differ from a Java based
client solution using CORBA or RMI?
In short, Classic Blends Presentation server provides
a higher performance, more highly responsive, and more easily created and
maintained client solution than is developed using CORBA or RMI.
CORBA and RMI generally represent overkill for just distributing the GUI. Often when using CORBA or RMI you will send objects to the client only to display the client first/last name. The rest of the object is "thrown away". Sending objects that are not used creates more network traffic than necessary and requires the user to program on the client and server. There is substantially more overhead in a CORBA message than in a Classic Blend message, which has its transport protocol optimized for supporting thin client to application server messages. Also, in CORBA and RMI solutions, a separate message is required for each type of read or write query that client needs the application server to support. Classic Blend does not require that specialized application server queries be created and maintained since the presentation logic is left on the application server.
In addition Classic Blend has been optimized for presentation serving. Classic Blend has been optimized to reduce the size of network packets and reduce to number of network "round-trip" messages required when connecting a thin client to an application server.
What are the bandwidth requirements
of Classic Blend?
If you deploy Classic Blend as a download-on-demand applet,
the applet (which is 250 KB) will have to be downloaded each time. Once
the applet is downloaded, the GUI definitions for your application are
downloaded. The GUI definitions will obviously vary but for complex applications
expect 5k-14k for simple applications. (There exist a number of solutions
that can eliminate this download cost to one time ever û Microsoft cabinets,
Castanet, etc.) After the GUI definitions are downloaded, subsequent network
traffic averages on the order of bytes, not kilobytes. Customers have been
very successful deploying with Classic Blend over 28.8K modems.
Can I fit a "big" application on a
tiny Network Computer?
One of the key characteristics of the Classic Blend architecture
is that it employs a universal client that works for all applications.
This means that the only parts of a running application that resides on
the client machine is the universal Classic Blend client, and a small piece
of code that defines the interface layout. The application logic and business
objects all reside on the server. As the application grows in features
and size, the client stays virtually the same size, while the server grows.
This sounds a lot like X-Windows or
WinFrame. Is it?
In some ways it is. Both Classic Blend and WinFrame solutions
allow the developer to focus on writing application logic code with little
or no concern for the division between client and server. However, architecturally,
Classic Blend and X-Windows/WinFrame are very different. Classic Blend
places the actual interface objects (windows, widgets, etc) on the client.
X-Windows/WinFrame places just the display on the client and emulates all
of the interface objects on the server. Emulating the interface objects
on the server requires that every event and repaint is sent between the
client and server, resulting in a significant burden being placed on the
server machine and bandwidth required. In contrast, the Classic Blend architecture
leverages the processing power on the client to perform the low-level widget
interactions such as events and repaints, and only high-level events (such
as list selections or button presses) are sent to the server. In addition,
the Classic Blend widget proxies have been optimized to intelligently cache
and forward messages.
The client/server division that is created by Classic Blend is empirically the optimal one. This is because most semantically significant events require domain interaction (e.g. database queries, updates, etc.) in order to determine a response and so will need to go to the server for processing. At the same time, the architecture avoids excessive client and server interactions that are the Achilles heel of the X-Windows/WinFrame solution.
But canÆt Java on the client deliver
the same thing?
Java on the client can certainly provide the same functionality
but at a much greater effort. The effort comes from the networking aspect.
Networking applications require tuning and special tools for debugging.
If developers aren't experienced at writing networking applications, they'll
have a continuing growth experience as they learn more and more about networking,
in order to figure out why they can't even connect the server to the client.
In addition, with technologies such as CORBAor RMI, the slightest change
to your objects can require a regeneration of network or stub code, thus
requiring updates to all clients. Because Classic Blend is only concerned
with representing the visual aspects of your application, changes to your
domain objects will not require changes to the client code.